Вопрос - доступ к сервисам по внешнему домену

Всем привет.

Приобрел nas ds211j. Пока все устраивает, есть свои нюансы, но они не сильно напрягают.

Сейчас основной вопрос - хочу иметь доступ к File Station и DSM извне (из других сетей). Для этого завел платный домен вида mmmmm.info

В нем завел два субдомена, каждый из которых соотвествует File Station и DSM. И форварднул их соответственно на свой фиксированный внешний айпишник с соответствующими портами 7000 и 5000, которые в свою очередь проброшены в роутере.

Теперь вопрос - почему из других сетей я спокойно получаю доступ к этим службам по соотвествующим субдоменам, а из своей сети - такого не получается? Браузер подвисает, а потом выдает ошибку типа "Oops! Google Chrome could not connect to <мой фикс айпи:соотв.порт>"

Подозреваю, что может быть nas и не при чем... Но, развейте мои сомнения плз. Можно ли как то сию ситуацию исправить?

Заранее спасибо.

Обращайся к насу из внутренней сети по его внутреннему адресу.

Ежели хочется обратиться по имени dsm.mmmmm.info - сделай соответствующую запись в свой файл hosts.

Обращайся к насу из внутренней сети по его внутреннему адресу.

Ежели хочется обратиться по имени dsm.mmmmm.info - сделай соответствующую запись в свой файл hosts.

Спасибо за совет. Если не сложно, подскажи плз, файл hosts должен лежать в \web\etc ?

И формат должен быть - <внутренний айпи адрес хранилища:порт dms> пробел dms.mmmmm.info ?

Спасибо.

Спасибо за совет. Если не сложно, подскажи плз, файл hosts должен лежать в \web\etc ?

И формат должен быть - пробел dms.mmmmm.info ?

 

Спасибо.

Нужно править тот hosts, который лежит на компе, с которого Вы заходите на накопитель. Обычно это C:\Windows\System32\drivers\etc.

Выглядеть он должен примерно так:

192.168.1.2 dsm.mmmmm.info

Но порт в hosts прописать нельзя, насколько я помню. Так что заходить придется по адресу dsm.mmmmm.info:5000.

Нужно править тот hosts, который лежит на компе, с которого Вы заходите на накопитель. Обычно это C:\Windows\System32\drivers\etc.

 

Выглядеть он должен примерно так:

 

192.168.1.2 dsm.mmmmm.info

 

Но порт в hosts прописать нельзя, насколько я помню. Так что заходить придется по адресу dsm.mmmmm.info:5000.

Благодарю. Вечером попробуем-с

Всем добрый день!

Присоединяюсь к вопросу, но немного его расширю.

Ситуация следующая. Например, мы подключаем сетевой диск по WebDAV:

1. Из внешней сети адрес диска выглядит как "https://www.hostname.ru:5006/home" (в XP и MacOS можно прямо из проводника, для Win7 используем, например, NetDrive). Все работает замечательно.

2. Из внутренней сети так сделать не получается, приходится подключаться как (в моем случае): "https://192.168.100.208:5006/home".

Хочется, чтобы клиент имел возможность подключаться к хранилищу (в моем случае - RS-810+RP) как из внутренней, так и из внешней сети именно по ссылке вида "https://www.hostname.ru:5006/home". Удобство очевидно.

У пользователей собственные ноуты, причем операционки у всех разные - от XP и MacOS до Убунту (всего человек 100), поэтому вариант с настройкой чего-либо на "клиентской" части (типа правки hosts) отпадает сам собой.

Понятно, что вопрос относится не к работе систем Synology, а к сетевому администрированию, но если гуру подскажут, какова должна быть логика настройки шлюза для реализации подобной функциональности (или хотя бы "ткнут" в нужный мануал) - то, мне кажется, не только я, но и многие другие здесь будут очень признательны.

Спасибо заранее!

С Уважением,

Алексей.

Для доступа по имени из внутренней сети адрес www.hostname.ru должен быть известен клиентам этой внутренней сети.

Наверняка внутренняя сеть организуется маршрутизатором со своим DHCP. Соответственно клиенты используют в качестве DNS какой-то внутренний IP, чаще это IP маршрутизатора.

Вот в этом маршрутизаторе и надо поправить файл hosts, добавить в него соответствие 192.168.100.208 www.hostname.ru

Так как то...

Для доступа по имени из внутренней сети адрес www.hostname.ru должен быть известен клиентам этой внутренней сети.

Наверняка внутренняя сеть организуется маршрутизатором со своим DHCP. Соответственно клиенты используют в качестве DNS какой-то внутренний IP, чаще это IP маршрутизатора.

Вот в этом маршрутизаторе и надо поправить файл hosts, добавить в него соответствие 192.168.100.208 www.hostname.ru

 

Так как то...

Спасибо за совет,

но так точно ничего не получится: www.hostname.ru - это имя _шлюза_, а не клиента с внутренним адресом 192.168.100.208, и мне совершенно не надо перебрасывать весь трафик с маршрутизатора на хранилище!

Еще раз:

1. Внешний статический ip маршрутизатора (шлюза) - 195.194.193.192, соответствующее имя - www.hostname.ru. Он прекрасно виден из всех сегментов сети (как из локалки, так и из внешней сети), причем как по имени, так и по ip.

Например, я могу из локалки зайти на него по ssh как "ssh [email protected]"; точно таким же способом - из внешней сети.

2. На маршрутизаторе, помимо прочих служб, работает dhcp-сервер, который раздает адреса машинам в локальной сети. Одним интерфейсом маршрутизатор смотрит в интернет, другим - в локальную сеть. Внутренний адрес маршрутизатора - 192.168.100.1.

3. Локальные машины получают адреса из диапазона, скажем, 192.168.100.100-192.168.100.200; для тех устройств, к которым требуется доступ извне, зарезервированы фиксированные адреса из диапазона 192.168.100.201-192.168.100.240.

4. В локальной сети работает хранилище Synology 810+RP, для него зарезервирован адрес 192.168.100.208.

5. Для того, чтобы пользователи могли получать доступ к хранилищу из "внешнего мира", на маршрутизаторе проброшены на внутренний адрес 192.168.100.208 все необходимые порты (5000, 5001, 5005, 5006 и пр.). Соответственно, когда пользователь, находящийся _вне_ локальной сети, отправляет на адрес 195.194.193.192 запрос по одному из этих портов (например, 195.194.193.192:5005 или *.192:5006 и т.п.), эти запросы автоматически перенаправляются на внутренний адрес 192.168.100.208:<номер_порта>. Перенаправление корректно функционирует и в случае, когда пользователь обращается по доменному имени ("http://www.hostname.ru:<номер_порта>"), и в случае, когда пользователь обращается по ip ("http://195.194.193.192:<номер_порта>"). Именно так схема и должна работать, и она прекрасно работает.

Но возникает проблема:

Как только пользователь пытается таким же способом обратиться к хранилищу, находясь именно _внутри_ локальной сети, маршрутизатор форвардировать запрос на внутренний адрес хранилища отказывается. Не перенаправляются ни запросы вида "http://www.hostname.ru:<номер_порта>", ни запросы вида "http://195.194.193.192:<номер-порта>". Для того, чтобы получить доступ к хранилищу, пользователю приходится непосредственно указывать именно его внутренний адрес ("http://192.168.100.208:<номер_порта>").

То есть, если я хочу обратится из локальной сети по внешнему имени или ip к самому маршрутизатору (например, как "ssh [email protected]", или по telnet, или по ftp и т.д.), то - пожалуйста;

а если я хочу обратится из локальной сети по внешнему имени или ip к какой-либо локальной машине - то запросы корректно не отрабатываются.

Вопрос в том, что мне необходимо сделать, чтобы исправить ситуацию...

Еще раз спасибо всем заранее за ответы!

С Уважением,

Алексей.

Я так и написал.

Попробую ещё разок.

Для клиентов внутренней сети адрес 195.194.193.192 мёртвый. Обращение к нему ничего не даёт. Такова специфика твоего NAT. Как бы тебе "на пальцах" объяснить...

Во.... Ты живёшь в квартире. Путь на работу пролегает примерно так: комната - коридор - дверь - улица и т.д. За хлебом так же. Да, у тебя всегда с собой есть ключи от своей двери.

И тут тебе надо из комнаты сходить на кухню. Ты по проторенному пути выходишь на лестницу, захлопываешь дверь, а ключи оставляешь дома(а зачем они, я ведь только на кухню иду) и пытаешься уже попасть на эту кухню. Но в квартиру то уже нет хода.

Есть более короткий путь - комната - коридор - кухня.

Теперь переложу этот бред на IP и имена хостов.

Клиент внутренней сети набрал адрес www.hostname.ru. Браузер спросил у своего днс ИП, получил 195.194.193.192 и пошёл подключаться. Ага, читает мой бред про "длинный путь на кухню".

Необходимо добиться, что-бы при обращении к www.hostname.ru из внутренней сети днс выдавал ИП 192.168.100.208, а при обращении из инета 195.194.193.192.

Как это сделать, я описал в своём после выше.

ЗЫ. Пока писал, вспомнил, что на своём DS обнаружил BIND-9.6.1. Прекрасный DNS сервер. Только настроить и запустить.

2ent:

Логика стала более прозрачной, спасибо.

Правильно ли я понял, что проблема исключительно в настройке dns?

И, если не сложно, проясните, пожалуйста, еще один момент: как тогда будет отрабатываться ситуация, когда мне нужно получать изнутри сети доступ не только на "кухню", но и в другие комнаты тоже?)))

Вот клиент хочет обратиться из внешнего мира к локальной машине с локальным адресом *.208. Я пробросил на этот адрес не все, а строго определенные порты. Другие порты проброшены на другие локальные машины с другими локальными адресами (например, 60000 -> *.209, 62000 -> *.210 и т.д. В моем конкретном примере - это ip-камеры). Вся эта "схема" перенаправления портов находится на маршрутизаторе.

Если, следуя описанной процедуре, я установлю для локальных пользователей безусловное взаимооднозначное соответствие "www.hostname.ru <-> 192.168.100.208", то, по идее, все запросы по всем портам вида "www.hostname.ru", направленные из локальной сети, будут перекидываться на хранилище. А как тогда обеспечить доступ пользователей из локалки к остальным ресурсам локальной сети?..

С Уважением,

Алексей.

PS Для модераторов: если есть необходимость, перенесите, пожалуйста, тему в тот раздел, где обсуждение вопроса будет наиболее уместным. Спасибо!

Да, за это отвечает внутренний днс.

Если в сети присутствует нат, то, как правило, на обслуживающем внутреннюю сеть днс заводят зону, где общедоступным именам хостов приводят в соответствие внутренние адреса, дабы клиенты не испытывали дискомфорта при сёрфинге как из инета, так и изнутри.

В Вашей ситуации я, набравшись наглости, посоветую пересмотреть именование Ваших хостов.

Заведите на внешнем днс адреса cam1.hostname.ru, cam2.hostname.ru и тд. То же проделайте изнутри. Если маршрутизатор умеет портмаппинг, то совсем хорошо будет.

Все, теперь совсем понятно.

Почитал про разделенные зоны dns, скачал мануал по бинду, разбираюсь. Он на маршрутизаторе, как оказалось, и так поднят, я сейчас проверил))).

Спасибо за разъяснения!..

Единственное, что хотелось бы еще уточнить: если самостоятельно прописать форвард портов в роутере, следую многочисленным инструкциям, по силам почти любому "чайнику", то "поднять и настроить bind" - это, имхо, вряд ли.

Получается, что для "рядового" пользователя, у которого просто есть дома какой-нибудь примитивный роутер, имеется внешний выделенный ip, зарегистрировано доменное имя типа "www.myusername.ru" и заказан primary и secondary dns у какого-нибудь провайдера, шанс решить без посторонней помощи обозначенную мною проблему крайне мал?..

С Уважением,

Алексей.

P.S. Я "www.hostname.ru" для примера просто написал, там все нормально наывается: gate.hostname.ru, cameraX.hostname.ru и т.п. Просто к остальным ресурсам обращаться по-разному изнутри и снаружи было вполне удобно, а с системой хранения это крайне непрактично.

Единственное, что хотелось бы еще уточнить: если самостоятельно прописать форвард портов в роутере, следую многочисленным инструкциям, по силам почти любому "чайнику", то "поднять и настроить bind" - это, имхо, вряд ли.

Получается, что для "рядового" пользователя, у которого просто есть дома какой-нибудь примитивный роутер, имеется внешний выделенный ip, зарегистрировано доменное имя типа "www.myusername.ru" и заказан primary и secondary dns у какого-нибудь провайдера, шанс решить без посторонней помощи обозначенную мною проблему крайне мал?..

В идеале задача решается NAT loopback, когда пормаппинги работают из локалки, однако абсолютное большинство домашних игрушек этого не умеет

Остается обработка вашего доменного имени локальным адресом, что делается

- в случае небольшой сети/одного компьютера - файлом hosts

- в случае приличной сети - DNS сервером

К слову, поднимать bind конечно true way, но не единственное решение. Гораздо проще установить и почти не надо настраивать dnsmasq - есть в репозитории, минимум настроек

Начать надо с hosts, а потом, как сеть подрастать станет, замутить посложнее чего-нить.

ЗЫ: А bind то уже стоит (наверное на всех DS), только минимум настроек и стартовать его.

В результате, остановился на варианте с биндом; только развернул его на шлюзе, а не на rackstation'е.

Схема получилась не совсем такая, как я изначально предполагал: проще оказалось назвать rackstation как data.hostname.ru и сделать это имя доступным как изнутри сети, так и снаружи (спасибо, что обратили мое внимание на это))), чем реализовывать доступность выражения gate.hostname.ru:<номер_порта> из обеих "частей" сети.

В принципе, ничего особо сложного там нет даже для начинающего типа меня; за два дня разобраться вполне реально.

Всем спасибо за советы!

С Уважением,

Алексей.